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Abstract 

Polymorphic regular types are tree-like datatypes gen- 
erated by polynomial type expressions over a set of free 
variables and closed under least fixed point. The 'equal- 
ity types ' of Core ML can be expressed in this form. Given 
such a type expression T with x free, this paper shows a 
way to represent the one-hole contexts for elements of x 
within elements of T, together with an operation which 
will plug an element of x into the hole of such a context. 
One-hole contexts are given as inhabitants of a regular 
type d x T, computed generically from the syntactic struc- 
ture of T by a mechanism better known as partial differ- 
entiation. The relevant notion of containment is shown to 
be appropriately characterized in terms of derivatives and 
plugging in. The technology is then exploited to give the 
one-hole contexts for sub-elements of recursive types in a 
manner similar to Huet's 'zippers' [Hue97]. 



1 Introduction 

Gerard Huet's delightful paper 'The Zipper' [Hue97] de- 
fines a representation of tree-like data decomposed into a 
subtree of interest and its surroundings. He shows us in- 
formally how to equip a datatype with an associated type 
of 'zippers' — one-hole contexts representing a tree with 
one subtree deleted. Zippers collect the subtrees forking 
off step by step from the path which starts at the hole and 
returns to the root. This type of contexts is thus indepen- 
dent of the particular tree being decomposed or the sub- 
tree in the hole. Decomposition is seen not as a kind of 
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subtraction, an operation inherently troubled by the need 
to subtract only smaller things from larger, but as the in- 
version of a kind of addition (see figure 1). 




Figure 1: a tree as a one-hole context 'plus' a subtree 

This paper exhibits a similar technique, defined more for- 
mally, which is generic for a large class of tree-like data 
structures — the 'regular datatypes'. These are essentially 
the 'equality types' of core ML, presented as polynomial 
type expressions closed under least fixed point. In partic- 
ular, I will define and characterize two operations: 

• on types, computing for each regular recursive 
datatype its type of one-hole contexts; 

• on terms, computing a 'big' term by plugging a 
'small' term into a one-hole context. 

The first of these operations is given by recursion on the 
structure of the algebraic expressions which 'name' types. 
As I wrote down the rules corresponding to the empty 
type, the unit type, sums and products, I was astonished 
to find that Leibniz had beaten me to them by several cen- 
turies: they were exactly the rules of differentiation I had 
learned as a child. 
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1.1 Motivating Examples 



btree' = 2xbtree 



How can we describe the one-hole contexts of a recur- 
sive type? Huet suggests that we regard them as journeys 
'backwards' from hole to root, recording what we pass by 
on the way. I propose to follow his suggestion, except that 
I will start at the root and work my way 'forwards' to the 
hole. Both choices have their uses: 'backwards' is better 
for 'tree editing' applications, but the 'forwards' approach 
is conceptually simpler. 

Consider such journeys within binary trees: 

btree = leaf | node btree btree 

At each point, we are either at the hole or we must step 
further in — our journey is a list of steps, list btree' for 
some appropriate step type btree', but what? At each 
step, we must record our binary choice of left or right, 
together with the btree we passed by. We may take 

btree' = boolx btree 

We can define the 'plugging in' operation + as follows 1 

s e btree' t e btree 
s<ie btree 

(true, r) < t i-> nodetr 
(false, i) < * node Zt 

ss e list btree' t e btree 
ss + 1 e btree 

D + 1 H> t 
(s::ss)+t i-> s<(ss+t) 

We might define btree more algebraically as the sum 
(i.e. 'choice') of the unique leaf with nodes pairing two 
subtrees — powers denote repeated product: 

btree = 1 + btree 2 

Correspondingly, we might write 

'Huet would write (a :: ss) + t i-> ss + (s < t) 



Now imagine similar journeys list ttree' for ternary 
trees: 

ttree = 1 + ttree 3 

Each step chooses one of three directions, and remembers 
two bypassed trees, so 

ttree' = 3 x ttree 2 

It looks remarkably like the type of steps is calculated by 
differentiating the original datatype. In fact, this is exactly 
what is happening, as we shall see when we examine how 
to compute the description of the one-hole contexts for 
regular datatypes. 



2 Presenting the Regular Types 

In order to give a precise treatment of 'differentiating a 
datatype' , we must be precise about the expressions which 
define them. In particular, the availability of fixed points 
requires us to consider the binding of fresh type variables. 
There is much activity in this area of research, but this is 
not the place to rehearse its many issues. The approach 
I take in this paper relativizes regular type expressions to 
finite sequences of available free names. I then explain 
how to interpret such expressions relative to an environ- 
ment which interprets those names. 

I choose to give inductive definitions in natural deduc- 
tion style. Although this requires more space than the 
datatype declarations of conventional programming lan- 
guages, they allow dependent families to be presented 
much more clearly: even 'nested' types [BM98, BP99] 
must be defined uniformly over their indices, whilst the 
full notion of family allows constructors to apply only 
at particular indices. I also give type signatures to de- 
fined functions in this way, preferring to present the uni- 
versal quantification inherent in their type dependency via 
schematic use of variables, rather than by complex and in- 
scrutable formulae. 
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2.1 Sequences of Distinct Names 

Let us presume the existence of an infinite 2 set Name of 
names, equipped with a decidable equality. We may think 
of Name as being 'string' . The set NmSeq may then be 
defined to contain the finite sequences of distinct names. 
Each such sequence can be viewed 'forgetfully' as a set. 

g e NmSeq 

Name e Set S g Set 

g g NmSeq x g Name x g g 

e e NmSeq S;xg NmSeq 

I shall always use names in a well-founded manner. The 
'explanation' of some name x from some sequence S will 
involve only 'prior' names — intuitively, those which have 
already been explained. It is therefore important to define 
for any such pair, the restriction S [x, being the sequence 
of names from S prior to x. 

g e NmSeq x g g 
S [x g NmSeq 

S;x|.x i-> S 
S;(y\x)tx k> Six 

As equality on names is decidable, I shall freely allow 
names to occur nonlinearly in patterns. In order to re- 
cover the disjointness of patterns without recourse to pri- 
oritizing them, I introduce the notation y\x to mean 'any 
y except x\ Correspondingly, each clause of such a defi- 
nition holds (schematically) as an equation. I nonetheless 
write i-» to indicate a directed computation rule, reserving 
= for equational propositions. 

2.2 Describing the Regular Types 

The regular types over given free names, or rather, the ex- 
pressions which describe them are given by the inductive 

2 By 'infinite' , I mean that I can always choose a fresh name if I need 
to create a new binding. 



family Reg S in figure 2. Firstly, we embed 3 type vari- 
ables S in Reg S, then we give the building blocks for 
polynomials and least fixed point. 

g e NmSeq 
Reg S g Set 

X G S 

x g Reg S 

S,T g RegS 

0 g Reg S S + T g Reg S 

S, T g Reg g 

1 g RegS SxT g RegS 

F g RegS;x 
ixx.F g Reg S 

F g Reg S; x S g Reg S T g Reg S 
F\x=S g Reg S T_ x g Reg S; x 

Figure 2: descriptions of regular types 

The last two constructors may seem mysterious. How- 
ever, the redundancy they introduce will save us work 
when we come to interpret these descriptions of types. 
We could choose to interpret only Reg e, the closed de- 
scriptions, keeping the open types underwater like the 
dangerous bits of an iceberg. This would require us to 
substitute for free names whenever they become exposed, 
for example, when expanding a fixed point. We would in 
turn be forced to take account of the equational properties 
of substitutions and prove closure properties with respect 
to them. I dispense with substitution. 

The alternative I have adopted is to interpret open descrip- 
tions in environments which explain their free names. The 
two unusual constructors above perform the roles of defi- 
nition and weakening, respectively growing and shrinking 
the environment within their scope. Definition replaces 
substitution and weakening adds more free names without 
modifying 'old' descriptions. This avoids the propagation 
of substitutions through the syntactic structure and hence 
concerns about capture — we shall only ever interpret the 
'value' of a variable in its binding-time environment. 

3 In fact I am abusing notation by suppressing a constructor symbol. 
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2.3 Type Environments 

A type environment for a given name sequence X asso- 
ciates each x in X with a type description over the prior 
names, X [x. 



g e NmSeq 
Env X g Set 



X;x e NmSeq 



£ g Env e 
T g Env X 



g g Reg X 



T\x=S G EnvX;x 



We may equip environments with operators for restriction 
(extracting the prefix prior to a given name) and projection 
(looking up a name's associated type description), r [x is 
the environment which explains the free names in T ■ x. 



T g Env X x G X 
r |.x G EnvX|.x 



T g Env X x G X 
r ■ x g Reg X tx 



r ; x=5tx ^ r 

r ; (2/\x)=5Lx i-> rtx 

x = S m x ' ^ $ 

r ; (2/\x)=5-x i-> r-x 



r g Env X T g Reg X 

r [T] G Set 

fe rtx [r-x] 
t e r M 



g g r [51 



t g r [T] 



inlsGr[5 + T] inrtGT[5 + T] 

gGr|5i terjT] 

()GT[1] (s;t)er[SxT] 

t G r [F|x=/<x. F] 
con t g r \fix. FJ 

tGT;x=SlF] t G T [T] 

fGT[F|x=5J tGr ; x=5[T,J 



Figure 3: f/ze (iata in regular types 



2.5 Examples of Regular Types 

Let us briefly examine some familiar types in this setting. 
We have the unit type 1 , so we can use + to build the 
booleans: 



bool H> 1+1 

true H> inl {) 
false i-> inr {) 



(G Reg S, any S) 
(G T [bool] , any T) 
(G T [bool] , any T) 



2.4 Interpreting the Descriptions 

Now that we have the means to describe regular types, 
we must say which data are contained by the type with 
a given description, relative to an environment explaining 
its free names — we must give a semantics to the syntax. 
Figure 3 defines the interpretation T [T] inductively. 4 

Note that I have not supplied constructor symbols for the 
embedding rules corresponding to variable-lookup, def- 
inition and weakening. These apparent conflations of 
types, e.g. r;x=5 , [x] with are harmless, as the 

types tell us which embeddings are operative. 



4 The 'semantic brackets' do not represent a meta-level operation; 
they are intended to be a suggestive object-level syntax for a dependent 
family of types. 



We may use p, to build recursive datatypes like the natural 
numbers and our tree examples, again for any S and T, as 
a fresh bound variable (x below) can always be chosen: 

nat i y fix. 1 + x 
zero i-> con (inl ()) 
sucn con (inr n) 

btree i-> fix. 1 + xxx 
bleaf h> con (inl {)) 
bnode/r i-> con (inr (Z; r)) 



ttree 

tleaf 
tnode Z m r 



i-> ixx. 1 + xx (xxx) 

H> con (inl ()) 

H> con (inr (Z; (m;r))) 
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We may use weakening to define an operation which com- The effect of local type variables is thus reflected at their 
putes list types: place of binding, rather than at their places of use. 5 



list T H> fix. 1 + T x xx 

nil i — y con (inl {)) 
xv.xs h> con (inr (x; xs}) 

The finitely branching trees may thus be given by 

ftree i-» fix. list x 
fnode ts >-> con ts 



The significance of the phrase 'accounted for by the x's 
in T" is shown by this simple example: 



If we take 
we can derive 
but not 



T = £;x=bool;y=x 
true <% xy (true; false) 
false <% xy (true; false) 



The point is that false has type x on account of the x in 
this particular T's definition of y, whereas, irrespective of 
T, we can always derive 



2.6 Subterm Orderings for Regular Types 

Let us now define an inductive relation, u < x t for u £ 
T [x] and t € T [T], characterizing the sub terms of a term 
in T accounted for by x's in T. This relation characterizes 
T's role as a container of x's. I omit the obvious 'well- 
formedness' premises. 



u <l u 



u <% s 
<? +T inl s 



u <j t 

<? +T inr * 



s<**y (s;t) 

However, discharging the definition of y in our example: 

Taking T = £;x=bool 

we can derive true <* xy \ y ~ x (true; false) 

and false <% xy \ y=x (true; false) 

Both x's are accounted for by the indicated type, and the 
derivations follow respectively by the two definition rules. 

A similar phenomenon occurs if we try to specialize this 
ordering to the x's contained by a list x, that is, to deter- 
mine when 



t < x ts 



(s;t) 



u <i t 



(s;t) 



Only the rule for fixed points applies, showing this derived 
rule to be complete: 



u<^ v= " v - F t 
u <>i y F cont 



t *^-x ttS 

t < l } stx con its 



u <f t 
u<V y - S t 



s <? t 



u<P v = S t 



u <j t 
T 

U ^J" t 



Observe that subterms accounted for by an x in a compos- 
ite type are characterized by a rule for each component of 
that type. In particular, the rules for a definition F\y=S 
find subterms due to x's in F and x's in S respectively, 
the latter occurring within subterms due to y's in F. Note 
that the latter rule exploits the fact that we may see s as 
inhabiting both T [5] and T; y=S $yj. 



The premise can only be further simplified by the defini- 
tion rules: the direct rule finds only the head of the list in 
x; the indirect rule's second premise finds only the tail in 
y, and the first demands that we search for an x within that 
tail. We thus derive (and show complete) the two rules we 
might have hoped for: 



5 It would be interesting to investigate a notion of subterm with a 
single rule for definitions capturing 's-subterms within F-term t, re- 
membering that y really means S': however, we would pay with extra 
complexity in the rule for variables, and with the need to carry extra 
environmental information explicitly. 
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t <™ ta to 

t <f tx (t::to) t <f tx («::to) 

We may exploit this 'containment' relation to define the 
usual subterm relation for recursive types, namely < MX . p 
for r [/*£. F], as follows: 

U <n X .F S S < x _t 

u<^ x .fu u<^ x . f con t 

That is, to find a subterm of con t € T [p,y. FJ, either stop 
where you are, or move down one level to an x contained 
by F and repeat. cannot go further than one level, 
because x is free in F\ 

With a little work, we can specialize these rules for btree 
to 



t ^ btree t 

\_ ^ btree \ \_ ^ btree Jj 

t <btree (bnode / r) t <btree (bnode I r) 

3 One-Hole Contexts 

Let us now turn to the generic representation of one-hole 
contexts for recursive regular types. We shall first need to 
see what 'one step' is. 

The immediate recursive subterms in some con t of 
type T l/ix. F} are those subterms of t which correspond 
to the occurrences of x in F — recall that t has type 
T; x=/ix. F \F\. We therefore need to describe the one- 
hole contexts for x's in F's. Since F may itself contain 
fixed points, the primitive operation we need to define will 
compute for F the type of one-hole contexts for any of its 
free names. This operation is exactly partial differentia- 
tion. 

3.1 Partial Differentiation 

The partial derivative of a regular type description T with 
respect to a free name x is computed by structural recur- 



sion over the syntax of T. 6 It is defined in figure 4. 



x e g T g Reg S 
d x T g Reg S 



d x x 


H> 


1 


d x (y\x) 


H> 


0 


d x 0 


H> 


0 


d x (S + T) 


i-> 


d x S + d x T 


d x \ 


i-> 


0 


d x (SxT) 


i-> 


d x SxT + Sxd x T 


d x (ny.F) 


i-> 


fiz.d x F\y=fiy.F + 






d y F \y=ny. Fxz 


d x (F\y=S) 


H> 


d x F\y=S + d v F\y=Sxd x S 






0 


dxT.y\ x 







Figure 4: partial differentiation 

The first six lines are familiar from calculus. For one-hole 
contexts, they tell us that 

• an x contains one x in trivial surroundings 

• ay other than x contains no a; 

• constants contain no x 

• we find an x in an S + T in either an S or a T 

• we find an x in an Sx T either (left) in the S, passing 
the T, or (right) in the T passing the S 

Note that partial differentiation is independent of environ- 
ments: it is defined on the syntax of types alone. Just like 
the subterm ordering, it takes no account of the possibil- 
ity that some y might, for some T, expand in terms of x. 
However, partial differentiation is the basic tool by which 
total differentiation is constructed, and this is exactly what 
we need when we go under a binder and become liable to 
encounter local names which potentially do conceal x's. 

The rule for definitions again handles local variables at 
their place of binding, summing the types of contexts for 

6 It is depressing how few mathematics teachers deign to impart this 
vital clue to calculus students, giving them rules but no method. I learned 
differentiation from the pattern matching algorithm given in [McB70]. 
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x's occurring directly in F, and indirectly in an S buried 
within a y. In conventional calculus, this is effectively the 
'chain rule' extended to functions of two arguments 

= + £jf(u,v)§)\ {u , v)={a , b) 



IfT fF\x=0J s 0 fAen T [/*£. i**fl = 0 

Writing T" for the n-fold product of T's and n for the 
sum of n 1 's, we can check (by induction on n), that for 
n > 0 



in the special case where a is a;. 

Once we know how to differentiate definitions, we can 
make the leap to fixed points. If we expand the fixed point 
and apply the 'chain rule', we obtain: 

d x (py.F) = d x (F\y=fiy.F) 
= d x F\y=ny.F + 

d y F\y=ny.Fxd x (ny.F) 

It is tempting to solve this recursive equation with a least 
fixed point, but does this give the correct type of one-hole 
contexts? Yes: every x inside a jj,y. F must be a piece of 
'payload data' attached to some y-node buried at a finite 
depth. Hence our journey takes us either to an x at the 
outermost node and stops — hence the d x F in the 'base 
case' — or to a subnode and onwards — hence the d y F in 
the 'step case': it must stop eventually. We must weaken 
at z, for z is not free for F. Our journey is clearly linear: 
the body of the fixed point is syntactically linear in z. In- 
deed, the following set isomorphism holds, showing that 
our journey is a list of 'steps' with a 'tip': 

T\mz.ZU + S z xz] [(list S)xTj 

The rules for differentiating an explicit weakening simply 
short-circuit the process if the name we seek is that being 
excluded. 



Y\d x x n } nxx"- 1 

Viewed as a one-hole context for x n , the n tells us which 
x the hole is at, while the records the remaining x's. 

A more involved example finds an x within a list of x's 

enlist £ = d x (nyA + xxy) 

= nz.(d x (\ + xxy))\y=Hst x + 
{d y {\ + xxy))\y=Hst x xz 
= fiz. y\y=\ist x + a%=list xxz 
^ (list x) x (list "x) 

We would indeed hope that a one-hole context for a list 
element is a pair of lists — the prefix and the suffix! 

Amusingly, the following power series resembles list x, 

1+x + x 2 +x 3 H = y=~x ^ or l x l < 1 ) 

and conventional calculus tells us that 



~5x \T=x) ~ \T=x 
3.3 Plugging In 



3.2 Examples of Derivatives 

Before we develop any more technology, let us check that 
partial differentiation is giving us the kind of answers we 
expect. Of course, the types we get back will contain lots 
of '0+' and '1 x ', but the usual algebraic laws which sim- 
plify such expressions hold as set isomorphisms. It is also 
not hard to show that a recursive type with no base cases 
is empty: 



Given a one-hole context in d x T and an x, we should be 
able to construct a T by plugging the x in the hole. That 
is, we need an operation which behaves thus: 




r \x\ r [T] 



x\4i\ >-> 
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cer[d x r] ^er[x] 



0 {z<z} 


u 




inlc {5 + T<x} 


u 




inrc {5 + T<x} 


u 




inl <c;t) {5xT<4 


u 




inr <s;c) {5xT<x} 


u 


l-> 


con (inl c) {^.F<x} 


u 


H> 


con (inr (c; cs)) {^.F<a;} 


u 


H> 


inlc {F\y=S<x} 


u 


H> 


inr (cj,;^) {F y=5<x} 


u 


H> 


c {T yV <x\ 


u 





inl (c {S<x} u) 

inr (c {T<a;} u) 

(c {S<x} u;t) 

(s;c {T<x} u) 

con (c {F<x} u) 

con (c {-F<^} (cs {/iy.F<x} u)) 

c {F<x} u 

c y {F<y} (c x {S<x} u) 
c {T<x} u 



Figure 5: plugging in 



How are we to define this operation? T should tell us the 
shape of the term we are trying to build; c should tell us 
which path to take and also supply the subterms corre- 
sponding to the 'off-path' components of pairs. In effect, 
the operation proceeds by structural recursion on c, but its 
flow of control involves a primary case analysis on T. Of 
course, we need only consider cases where d x T is not 0. 
The definition is in figure 5. 



3.4 Subtrees in Recursive Regular Types 

The d x operation picks out x's from containers for x's. As 
suggested above, this gives us the tool we need to pick out 
subtrees from our tree-like recursive datatypes, interpret- 
ing t as a container for the immediate subtrees of con t. 
Hence our intuition that contexts for recursive type T in- 
habit list T' can be made rigorous. The 'step type' for 
trees in jix. F is 



ixx.F e Reg £ 
sub [ix. F e Reg S 



sub/ix.F h-> list {d x F \x=/ix. F) 



Informally, an inhabitant of sub /ix. F looks like 



:nil 




A few brief calculations reassure us that 



d x F \x=nx.F 



T [sub (list x)J 
hence T [sub (sub /ix. F)J 
T [sub btree] 
T [sub ttree] 
T [sub ftree] 



r [list xj 

r [sub ixx. F\ 
T[list (2 x btree)] 
T [[list (3xttree 2 )]] 
T [[list (list ftree) 2 ]] 



The one-hole contexts for /ix. F thus inhabit sub /ix. F 
given by 7 



7 Abuse of notation — sub is really an operation on F 



The corresponding notion of 'addition' has the signature 

cs g T [sub jxx. FJ iigT l/ix. Fj 
cs % x . F u G T\hx.F\ 
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For the 'cs' depicted above and an appropriate V, we 
expect cs + flx .p u to be 




Of course, + F is denned by iterating {F<x} over the 
list 8 : 

m\+^ xF u i-> u 
(c:: cs)+ flxF u i-> con (c {F<x} (cs \ xF u)) 

Observe, for example, that + nat really behaves like 'plus', 
whilst -)j ist x is effectively 'append' . It is not hard to show 
in general that sub fix. F is a monoid under 'append' and 
that + /lx F is an action of that monoid on fix. F. 

3.5 Subterms and Derivatives 

The relationship between the containment orderings and 
derivatives is an intimate one, and so too is that between 
the subtree orderings and the types computed by sub. In 
effect, the containment ordering is exactly that induced 
by plugging in, while the subtree ordering on fix. F is in- 
duced by + fix F . What we have done is to give a concrete 
representation for the witnesses to these relational prop- 
erties. We may prove the following theorems: 

Theorem (containment) 

For ueT [xj and t^T [Tj: 

u < T x t & 3c G T \d x Tj . c {T<x} u = t 

Theorem (subtree) 

For u,t£ TIpx.Fj: 

u <y, x .F 3cs e r [sub fix. FJ . cs+^ x F u = t 

The proofs of these theorems are easy inductions, on 
derivations for the =>- direction, and on the structure of 

8 Again, Huet would write 
{c::cs)\ x . F u ^ cs\ x F (con (c {F<x} u)) 



c or cs for the <£= direction. It is moreover the case that 
distinct c's or cs's on the right give rise to distinct deriva- 
tions on the left, and vice versa. I omit the details for 
reasons of space. 



4 Towards an Implementation 

Recent extensions to the HASKELL type system, such as 
Jansson and Jeuring's POLYP have begun to realise the 
potential of generic programming for the development 
of highly reusable code, instantiable for a wide class of 
datatypes and characterised by equally generic theorems 
[JJ97, BJJM98]. However, these systems show no sign of 
allowing operations like d x which compute types gener- 
ically by recursion over a closed syntax of type expres- 
sions, crucially regarding type variables as concrete ob- 
jects. 

In a dependent type theory supporting inductive families 
of datatypes [Dyb9 1 ] , syntaxes such as Reg £ can be rep- 
resented as ordinary data which can then be used to index 
the families like T [T] which reflect them. d x becomes 
merely an operation on data, requiring no extension to 
the computational power of the theory. A programming 
language based on such a type theory, as envisaged in 
[McB99], would seem to be a promising setting in which 
to implement the technology described in this paper. This 
work is well under way in the Computer-Assisted Reason- 
ing Group at Durham. 

The payoffs from such an implementation seem likely to 
be substantial, extending far beyond applications to edit- 
ing trees. A library of generic tools for working with con- 
texts would allow us to define functions in terms of these 
higher-level structures, manipulating data in large chunks, 
rather than one constructor at a time. Furthermore, in a 
dependently typed setting, a richer structure on data is 
ipso facto a richer structure on the indices of datatypes. 

It also seems highly desirable to extend the class of 
datatypes for which one-hole contexts can be manipulated 
generically beyond the regular types, perhaps to include 
indexed families themselves. A concrete representation 
of one-hole contexts for a syntax with binding has much 
to offer both metaprogramming and metatheory. 
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5 Conclusions and Future Work 

This paper has shown that the one-hole contexts for ele- 
ments contained in a polymorphic regular type can be rep- 
resented as the inhabitants of the regular type computed 
from the original by partial differentiation. This technol- 
ogy has been used to characterize data structures equiv- 
alent to Huet's 'zippers' — one-hole contexts for the sub- 
trees of trees inhabiting arbitrary recursive types in that 
class. The operations which plug appropriate data into 
the holes of such contexts have also been exhibited. 

While this connection seems unlikely to be a mere coinci- 
dence, it is perhaps surprising to find a use for the laws 
of the infinitesimal calculus in such a discrete setting. 
There is no obvious notion of 'tangent' or of 'limit' for 
datatypes which might connect with our intuitions from 
school mathematics. Neither can I offer at present any 
sense in which 'integration' might mean more than just 
'differentiation backwards' . 

One observation does, however, seem relevant: the syn- 
tactic operation of differentiating an expression with re- 
spect to x generates an approximation to the change in 
value of that expression by summing the contributions 
generated by varying each of the x's in the expression in 
turn. The derivative is thus the sum of terms correspond- 
ing to each one-hole context for an x in the expression. 
Perhaps the key to the connection can be found by fo- 
cusing not on what is being infinitesimally varied, but on 
what, for the sake of a linear approximation to the curve, 
is being kept the same. 

Apart from the implementation of this technology, and 
the development of a library of related generic utili- 
ties, this work opens up a host of fascinating theoretical 
possibilities — one only has to open one's old school text- 
books almost at random and ask 'what does this mean for 
datatypes?'. 

There must surely also be a relationship between this 
work and Joyal's general characterization of 'species of 
structure' in terms of their Taylor series [Joy87]. For reg- 
ular types, d%T makes a hole for a second x in a one-hole 
context from d x T. More generally, 9™T gives all the n- 
hole contexts for x's in T's in each of the n\ orders with 
which they can be found. This strong resonance with Tay- 



lor series seems worthy of pursuit and is an active topic of 
research. 

In summary, the establishment of the connection between 
contexts and calculus is but the first step on a long road — 
who knows where it will end? 
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